<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Exporters | ElasticSearch 7.7 权威指南中文版</title>
	<meta name="keywords" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <meta name="description" content="ElasticSearch 权威指南中文版, elasticsearch 7, es7, 实时数据分析，实时数据检索" />
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
	<script>
	var _link = 'es-monitoring-exporters.html';
    </script>
</head>
<body>
<div class="main-container">
    <section id="content">
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.7/es-monitoring-exporters.html" rel="nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/7.7/es-monitoring-exporters.html</a>, 原文档版权归 www.elastic.co 所有<br/>本地英文版地址: <a href="../en/es-monitoring-exporters.html" rel="nofollow" target="_blank">../en/es-monitoring-exporters.html</a></div>
                        <!-- start body -->
                  <div class="page_header">
<strong>重要</strong>: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html" rel="nofollow">当前版本文档</a>。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch Guide [7.7]</a></span>
»
<span class="breadcrumb-link"><a href="monitor-elasticsearch-cluster.html">Monitor a cluster</a></span>
»
<span class="breadcrumb-link"><a href="collecting-monitoring-data.html">Collecting monitoring data using legacy collectors</a></span>
»
<span class="breadcrumb-node">Exporters</span>
</div>
<div class="navheader">
<span class="prev">
<a href="es-monitoring-collectors.html">« Collectors</a>
</span>
<span class="next">
<a href="local-exporter.html">Local exporters »</a>
</span>
</div>
<div class="section xpack">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="es-monitoring-exporters"></a>Exporters<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/monitoring/exporters.asciidoc">edit</a><a class="xpack_tag" href="https://www.elastic.co/subscriptions"></a>
</h2>
</div></div></div>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>Metricbeat is the recommended method for collecting and shipping monitoring
data to a monitoring cluster.</p>
<p>If you have previously configured legacy collection methods, you should migrate
to using Metricbeat collection methods. Use either Metricbeat collection or
legacy collection methods; do not use both.</p>
<p>Learn more about <a class="xref" href="configuring-metricbeat.html" title="Collecting Elasticsearch monitoring data with Metricbeat"><em>Collecting monitoring data with Metricbeat</em></a>.</p>
</div>
</div>
<p>The purpose of exporters is to take data collected from any Elastic Stack
source and route it to the monitoring cluster. It is possible to configure
more than one exporter, but the general and default setup is to use a single
exporter.</p>
<p>There are two types of exporters in Elasticsearch:</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
<code class="literal">local</code>
</span>
</dt>
<dd>
The default exporter used by Elasticsearch monitoring features. This exporter routes data
back into the <em>same</em> cluster. See <a class="xref" href="local-exporter.html" title="Local exporters">Local exporters</a>.
</dd>
<dt>
<span class="term">
<code class="literal">http</code>
</span>
</dt>
<dd>
The preferred exporter, which you can use to route data into any supported
Elasticsearch cluster accessible via HTTP. Production environments should always use a
separate monitoring cluster. See <a class="xref" href="http-exporter.html" title="HTTP exporters">HTTP exporters</a>.
</dd>
</dl>
</div>
<p>Both exporters serve the same purpose: to set up the monitoring cluster and route
monitoring data. However, they perform these tasks in very different ways. Even
though things happen differently, both exporters are capable of sending all of
the same data.</p>
<p>Exporters are configurable at both the node and cluster level. Cluster-wide
settings, which are updated with the
<a class="xref" href="cluster-update-settings.html" title="Cluster update settings API"><code class="literal">_cluster/settings</code> API</a>, take precedence over
settings in the <code class="literal">elasticsearch.yml</code> file on each node. When you update an
exporter, it is completely replaced by the updated version of the exporter.</p>
<div class="important admon">
<div class="icon"></div>
<div class="admon_content">
<p>It is critical that all nodes share the same setup. Otherwise,
monitoring data might be routed in different ways or to different places.</p>
</div>
</div>
<p>When the exporters route monitoring data into the monitoring cluster, they use
<code class="literal">_bulk</code> indexing for optimal performance. All monitoring data is forwarded in
bulk to all enabled exporters on the same node. From there, the exporters
serialize the monitoring data and send a bulk request to the monitoring cluster.
There is no queuing—​in memory or persisted to disk—​so any failure during the
export results in the loss of that batch of monitoring data. This design limits
the impact on Elasticsearch and the assumption is that the next pass will succeed.</p>
<p>Routing monitoring data involves indexing it into the appropriate monitoring
indices. Once the data is indexed, it exists in a monitoring index that, by
default, is named with a daily index pattern. For Elasticsearch monitoring data, this is
an index that matches <code class="literal">.monitoring-es-6-*</code>. From there, the data lives inside
the monitoring cluster and must be curated or cleaned up as necessary. If you do
not curate the monitoring data, it eventually fills up the nodes and the cluster
might fail due to lack of disk space.</p>
<div class="tip admon">
<div class="icon"></div>
<div class="admon_content">
<p>You are strongly recommended to manage the curation of indices and
particularly the monitoring indices. To do so, you can take advantage of the
<a class="xref" href="local-exporter.html#local-exporter-cleaner" title="Cleaner service">cleaner service</a> or
<a href="https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html" class="ulink" target="_top">Elastic Curator</a>.</p>
</div>
</div>
<p>There is also a disk watermark (known as the flood stage
watermark), which protects clusters from running out of disk space. When this
feature is triggered, it makes all indices (including monitoring indices)
read-only until the issue is fixed and a user manually makes the index writeable
again. While an active monitoring index is read-only, it will naturally fail to
write (index) new data and will continuously log errors that indicate the write
failure. For more information, see <a class="xref" href="modules-cluster.html#disk-based-shard-allocation" title="Disk-based shard allocation settings">Disk-based shard allocation settings</a>.</p>
<h4>
<a id="es-monitoring-default-exporter"></a>Default exporters<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/monitoring/exporters.asciidoc">edit</a>
</h4>
<p>If a node or cluster does not explicitly define an exporter, the following
default exporter is used:</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">xpack.monitoring.exporters.default_local: <a id="CO440-1"></a><i class="conum" data-value="1"></i>
  type: local</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO440-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>The exporter name uniquely defines the exporter, but it is otherwise unused.
When you specify your own exporters, you do not need to explicitly overwrite
or reference <code class="literal">default_local</code>.</p>
</td>
</tr>
</table>
</div>
<p>If another exporter is already defined, the default exporter is <em>not</em> created.
When you define a new exporter, if the default exporter exists, it is
automatically removed.</p>
<h4>
<a id="es-monitoring-templates"></a>Exporter templates and ingest pipelines<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elastic/elasticsearch/edit/7.7/docs/reference/monitoring/exporters.asciidoc">edit</a>
</h4>
<p>Before exporters can route monitoring data, they must set up certain Elasticsearch
resources. These resources include templates and ingest pipelines. The
following table lists the templates that are required before an exporter can
route monitoring data:</p>
<div class="informaltable">
<table border="1" cellpadding="4px">
<colgroup>
<col class="col_1">
<col class="col_2">
</colgroup>
<thead>
<tr>
<th align="left" valign="top">Template</th>
<th align="left" valign="top">Purpose</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" valign="top"><p><code class="literal">.monitoring-alerts</code></p></td>
<td align="left" valign="top"><p>All cluster alerts for monitoring data.</p></td>
</tr>
<tr>
<td align="left" valign="top"><p><code class="literal">.monitoring-beats</code></p></td>
<td align="left" valign="top"><p>All Beats monitoring data.</p></td>
</tr>
<tr>
<td align="left" valign="top"><p><code class="literal">.monitoring-es</code></p></td>
<td align="left" valign="top"><p>All Elasticsearch monitoring data.</p></td>
</tr>
<tr>
<td align="left" valign="top"><p><code class="literal">.monitoring-kibana</code></p></td>
<td align="left" valign="top"><p>All Kibana monitoring data.</p></td>
</tr>
<tr>
<td align="left" valign="top"><p><code class="literal">.monitoring-logstash</code></p></td>
<td align="left" valign="top"><p>All Logstash monitoring data.</p></td>
</tr>
</tbody>
</table>
</div>
<p>The templates are ordinary Elasticsearch templates that control the default settings and
mappings for the monitoring indices.</p>
<p>By default, monitoring indices are created daily (for example,
<code class="literal">.monitoring-es-6-2017.08.26</code>). You can change the default date suffix for
monitoring indices with the <code class="literal">index.name.time_format</code> setting. You can use this
setting to control how frequently monitoring indices are created by a specific
<code class="literal">http</code> exporter. You cannot use this setting with <code class="literal">local</code> exporters. For more
information, see <a class="xref" href="monitoring-settings.html#http-exporter-settings" title="HTTP Exporter Settings">HTTP Exporter Settings</a>.</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>Some users create their own templates that match <em>all</em> index patterns,
which therefore impact the monitoring indices that get created. It is critical
that you do not disable <code class="literal">_source</code> storage for the monitoring indices. If you do,
Kibana monitoring features do not work and you cannot visualize monitoring data
for your cluster.</p>
</div>
</div>
<p>The following table lists the ingest pipelines that are required before an
exporter can route monitoring data:</p>
<div class="informaltable">
<table border="1" cellpadding="4px">
<colgroup>
<col class="col_1">
<col class="col_2">
</colgroup>
<thead>
<tr>
<th align="left" valign="top">Pipeline</th>
<th align="left" valign="top">Purpose</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" valign="top"><p><code class="literal">xpack_monitoring_2</code></p></td>
<td align="left" valign="top"><p>Upgrades X-Pack monitoring data coming from X-Pack
5.0 - 5.4 to be compatible with the format used in 5.5 monitoring features.</p></td>
</tr>
<tr>
<td align="left" valign="top"><p><code class="literal">xpack_monitoring_6</code></p></td>
<td align="left" valign="top"><p>A placeholder pipeline that is empty.</p></td>
</tr>
</tbody>
</table>
</div>
<p>Exporters handle the setup of these resources before ever sending data. If
resource setup fails (for example, due to security permissions), no data is sent
and warnings are logged.</p>
<div class="note admon">
<div class="icon"></div>
<div class="admon_content">
<p>Empty pipelines are evaluated on the coordinating node during indexing and
they are ignored without any extra effort. This inherently makes them a safe,
no-op operation.</p>
</div>
</div>
<p>For monitoring clusters that have disabled <code class="literal">node.ingest</code> on all nodes, it is
possible to disable the use of the ingest pipeline feature. However, doing so
blocks its purpose, which is to upgrade older monitoring data as our mappings
improve over time. Beginning in 6.0, the ingest pipeline feature is a
requirement on the monitoring cluster; you must have <code class="literal">node.ingest</code> enabled on at
least one node.</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>Once any node running 5.5 or later has set up the templates and ingest
pipeline on a monitoring cluster, you must use Kibana 5.5 or later to view all
subsequent data on the monitoring cluster. The easiest way to determine
whether this update has occurred is by checking for the presence of indices
matching <code class="literal">.monitoring-es-6-*</code> (or more concretely the existence of the
new pipeline). Versions prior to 5.5 used <code class="literal">.monitoring-es-2-*</code>.</p>
</div>
</div>
<p>Each resource that is created by an exporter has a <code class="literal">version</code> field,
which is used to determine whether the resource should be replaced. The <code class="literal">version</code>
field value represents the latest version of monitoring features that changed the
resource. If a resource is edited by someone or something external to the
monitoring features, those changes are lost the next time an automatic update
occurs.</p>
</div>
<div class="navfooter">
<span class="prev">
<a href="es-monitoring-collectors.html">« Collectors</a>
</span>
<span class="next">
<a href="local-exporter.html">Local exporters »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>